The build currently fails; could you please fix it? You may need to build with --all-features and with --no-default-features to reproduce the errors.

Also, this PR raises a Clippy error:

error: using `clone` on type `FileOptions<()>` which implements the `Copy` trait
Error:    --> examples/write_dir.rs:106:47
    |
106 |             zip.add_directory(path_as_string, options.clone())?;
    |                                               ^^^^^^^^^^^^^^^ help: try removing the `clone` call: `options`
    |
    = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy
    = note: `-D clippy::clone-on-copy` implied by `-D warnings`
    = help: to override `-D warnings` add `#[allow(clippy::clone_on_copy)]`

Hi,

It turns out that having a public trait extend a private trait was actually an error until Rust 1.74 (rust-lang/rust#113126, https://doc.rust-lang.org/error_codes/E0445.html) which has only been stable since November. Is there another way you can implement the sealing so that we don't have to bump the MSRV that far?

Hi,

It turns out that having a public trait extend a private trait was actually an error until Rust 1.74 (rust-lang/rust#113126, doc.rust-lang.org/error_codes/E0445.html) which has only been stable since November. Is there another way you can implement the sealing so that we don't have to bump the MSRV that far?

I think this works

Thanks; this will be merged automatically provided the tests pass.

Whoops, looks like some of your commits aren't signed! I'd suggest squashing the PR so that you only have to sign one.

Please stop merging every commit into my PR.

A. I rather use Rebase
B. That was a completely irrelevant file that does not require merging.

If you are not doing that. Then what is Github doing? I have never had a PR auto-merge commits like this.

After your squash and force-push, I'm still seeing:

"Merging is blocked
The base branch requires all commits to be signed. Learn more about signing commits."

This indicates that GitHub still doesn't recognize your signature. When it's recognized, you'll be able to see a Verified badge on the commit on the source branch's page.

This repo's main branch has the "Require branches to be up to date before merging" rule, to prevent merging two PRs that were compatible with their last common ancestor but not with each other (e.g. because they add different new functions with the same name).

After your squash and force-push, I'm still seeing:

Yeah I had done it in two separate actions. I have never setup Git Signing before. So It took me a moment.

Please don't close and reopen the PR unless you've rebased it, because then the CI checks are ignored and I have to manually approve them to start again. (If you've rebased it, then it's fine, because I'd have to restart them anyway.)

It looks like displaying a "Rebase branch" button instead of "Update branch" is in a lot of people's wish lists: https://github.com/orgs/community/discussions/3245 In future, I'll try to remember to check whether rebasing is an option; but it may not be if it would invalidate your signatures. (You'd think that if that happened, GitHub would be able to replace the signatures with ones of its own; not sure why that isn't implemented.)

It looks like displaying a "Rebase branch" button instead of "Update branch" is in a lot of people's wish lists: https://github.com/orgs/community/discussions/3245 In future, I'll try to remember to check whether rebasing is an option; but it may not be if it would invalidate your signatures. (You'd think that if that happened, GitHub would be able to replace the signatures with ones of its own; not sure why that isn't implemented.)

I just wish it would block it. Let me handle the merge or rebase. Don't do it automatically.

That means the CI can't run until you've rebased and I've approved the rebase to have the CI run on it, so PRs would take even longer to be merged. Plus, I may not be able to check PRs daily in the future -- I'm currently on leave from work, but will be either returning to full-time work or searching for a new job starting in early May, which may cause further delays. This is especially true if https://github.com/orgs/community/discussions/119719 and https://github.com/orgs/community/discussions/119723 turn out not to be the last issues of their kind that I'll get temporarily stuck on, or if #26 and #27 aren't the last config changes I'll discover a need for while others' PRs are waiting on CI. I'm fairly new at receiving PRs from other humans on a repo in parallel with each other and with my own work on the same repo, so there may be a lot of gotchas I've yet to discover. Please continue to be patient.

Thanks! This is now merged, and I expect to release it in version 1.1.0 within the next few days.